Method And System For Simulating A Plurality Of Devices

ABSTRACT

A method and system for simulating a plurality of devices are disclosed. A simulator configured to simulate a plurality of devices may output simulated device data for the plurality of devices, where the output of the simulated device data may be performed based upon execution of commands by the simulator. The commands may be received from a device abstraction layer in response to a request from the simulator for any commands associated with the plurality of devices. Additionally, the simulated device data may be communicated to a component coupled to the simulator, where a result of the processing of the simulated device data by the component may be used to analyze the performance of the component. Further, other commands may be executed by simulator for changing the frequency at which simulated device data is output, for performing another operation defined during configuration of the simulator, etc.

RELATED APPLICATIONS

The present application is related to U.S. patent application Ser. No.______, filed ______, entitled “METHOD, SYSTEM, AND GRAPHICAL USERINTERFACE FOR CONFIGURING A SIMULATOR TO SIMULATE A PLURALITY OFDEVICES,” naming Michael Biltz, Jonathan Hsu, Sean Stauth, and GraemeMacDonald as inventors, assigned to the assignee of the presentinvention, and having attorney docket number ACNR-D08-062/02006-00/US.That application is incorporated herein by reference in its entirety andfor all purposes.

BACKGROUND OF THE INVENTION

Simulation is often used to monitor, debug or otherwise analyze a systemor device. For example, a component designed to access an analog signaloutput by a sensor may be tested using a sensor simulator. The sensorsimulator may be coupled to the component or device under test, where asimulated signal voltage may be accessed by the device under test foranalysis thereof.

One type of conventional sensor simulator that is commercially availableprovides for single-sensor simulation. In other words, the softwareand/or hardware only provides a simulated output for a single sensor,and therefore, is not scalable. Additionally, conventional sensorsimulators simulate the signal characteristics of a signal output by asensor, e.g., a voltage level, etc. Therefore, conventional sensorsimulators do not provide for good simulation of a sensor designed tooutput digital data in packetized formats.

Although systems with few devices may be analyzed using conventionalsimulators, conventional simulators are not suitable for analyzingsystems with a large number of devices. For example, systems formonitoring or tracking data from automobiles, other vehicles,manufacturing sensors, or the like, often involve thousands or evenmillions of devices.

Accordingly, many instances of a conventional, single-device simulatorwould have to be individually created and configured to enablesimulation of the numerous devices, thereby providing a costly andinefficient solution. Additionally, even if such a solution wereimplemented, the large amount of information output by the individualsimulators would require extensive and costly processing resources.Moreover, given that conventional simulators output a simulated signalvoltage which must be converted or otherwise processed to produce usabledata, the amount of processing resources is further increased and theexisting problems are exacerbated.

SUMMARY OF THE INVENTION

Accordingly, a need exists for a device simulation system which enablesa user to more easily and efficiently define a large number of devicesfor simulation. A need exists for a device simulation system that cansimultaneously provide simulated responses, e.g., outputs, for a verylarge number of simulated sensors so that a real world system designedto interface with the simulated sensors can be adequately tested withoutneeding the physical sensors. A need also exists for a device simulationsystem which enables a user to more easily and efficiently configure thedefined devices, ether individually or in groups. Further, a need existsfor such a simulator which generates simulated device data that iseasier and less costly to process. Embodiments of the present inventionprovide novel solutions to these needs and others as described below.

Embodiments of the present invention are directed to a method and systemfor simulating a plurality of devices. More specifically, a simulatorconfigured to simulate a plurality of devices may output simulateddevice data for the plurality of devices, where the output of thesimulated device data may be performed based upon execution of commandsby the simulator. The commands may be received from a device abstractionlayer in response to a request from the simulator for any commandsassociated with the plurality of devices.

The simulated device data may include a data value (e.g., as opposed toa simulated voltage level). Additionally, the simulated device data maybe communicated to a component (e.g., of the device abstraction layer,of a business application coupled to the device abstraction layer, etc.)coupled to the simulator, where a result of the processing of thesimulated device data by the component may be used to analyze theperformance of the component. Further, in one embodiment, other commandsmay be executed by the simulator for changing the frequency at whichsimulated device data is output, for performing another operationdefined during configuration of the simulator, etc.

In one embodiment, a computer-implemented method of simulating aplurality of devices includes accessing configuration data for theplurality of devices and automatically instantiating the plurality ofdevices within computer memory based upon the configuration data,wherein the accessing and the automatic instantiation are performed by asimulator operable to be coupled to a system under test. Commandscommunicated from a device abstraction layer are accessed, wherein thecommands are associated with the plurality of devices. The plurality ofdevices are automatically simulated based upon execution of thecommands, wherein the automatic simulation comprises communicatingsimulated device data from the simulator to the system under test forperformance testing thereof. The commands may be requests for simulateddevice data associated with the plurality of devices, and wherein theautomatic simulation of the plurality of devices may further includeexecuting the commands and generating the simulated device data.Alternatively, a command of the commands may be a request to change anoutput frequency of simulated device data associated with the pluralityof devices. And in one embodiment, a command of the commands may be acustom command associated with at least one device of the plurality ofdevices.

In another embodiment, a method of simulating a plurality of devicesincludes configuring a simulator to simulate a plurality of devices,wherein the configuring comprises generating configuration data basedupon at least one user-defined attribute of the plurality of devices. Adevice abstraction layer is configured for communication with thesimulator, wherein the configuring of the device abstraction layerfurther comprises downloading the configuration data to a memoryaccessible to the device abstraction layer, wherein the deviceabstraction layer is a component of a system under test. Commandscommunicated from the device abstraction layer are accessed, wherein thecommands are associated with the plurality of devices. The method alsoincludes simulating the plurality of devices based upon execution of thecommands, wherein the simulation of the plurality of devices furthercomprises simulating the plurality of devices in accordance with theconfiguration data. The method may also include generating simulateddevice data in response to the execution of the commands, communicatingthe simulated device data to a component of the system under test (e.g.,of the device abstraction layer, of a business application coupled tothe device abstraction layer, etc.) coupled to the simulator, andanalyzing performance of the component based upon a result of processingof the simulated device data by the component.

And in yet another embodiment, a device simulation system includes asimulator for simulating a plurality of devices based upon configurationdata associated with the plurality of devices, wherein the configurationdata is associated with at least one user-defined attribute of theplurality of devices. A device abstraction layer is coupled to thesimulator, wherein the device abstraction layer comprises a memory forstoring the configuration data downloaded from the simulator, whereinthe device abstraction layer is further operable to implementcommunication with the simulator, and wherein the device abstractionlayer is further operable to communicate commands associated with theplurality of devices to the simulator. The simulator is further operableto simulate the plurality of devices based upon execution of thecommands to test a system associated with the device abstraction layer.The system may also include at least one business application coupled tothe device abstraction layer, wherein the device abstraction layer isfurther operable to implement communication between at least onebusiness application and the simulator. Using such a device simulationsystem as described above, the business application layer can adequatelybe tested without the need for large numbers of physical devices (e.g.,sensors).

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements.

FIG. 1 shows an exemplary system for accessing and processing data fromphysical devices in accordance with one embodiment of the presentinvention.

FIG. 2 shows an exemplary system for simulating a plurality of devicesin accordance with one embodiment of the present invention.

FIG. 3 shows an exemplary system for configuring a simulator andsimulating a plurality of devices based upon a specified configurationin accordance with one embodiment of the present invention.

FIG. 4A shows a first portion of a flowchart of an exemplarycomputer-implemented process for configuring a simulator and simulatinga plurality of devices based upon a specified configuration inaccordance with one embodiment of the present invention.

FIG. 4B shows a second portion of a flowchart of an exemplarycomputer-implemented process for configuring a simulator and simulatinga plurality of devices based upon a specified configuration inaccordance with one embodiment of the present invention.

FIG. 5A shows a first portion of a flowchart of an exemplarycomputer-implemented process for configuring a simulator in accordancewith one embodiment of the present invention.

FIG. 5B shows a second portion of a flowchart of an exemplarycomputer-implemented process for configuring a simulator in accordancewith one embodiment of the present invention.

FIG. 6 shows an exemplary on-screen computer-implemented graphical userinterface for configuring a simulator in accordance with one embodimentof the present invention.

FIG. 7 shows an exemplary on-screen computer-implemented graphical userinterface for defining a device profile in accordance with oneembodiment of the present invention.

FIG. 8 shows an exemplary on-screen computer-implemented graphical userinterface for defining a custom attribute in accordance with oneembodiment of the present invention.

FIG. 9 shows an exemplary on-screen computer-implemented graphical userinterface for creating a device based upon a device profile inaccordance with one embodiment of the present invention.

FIG. 10 shows an exemplary on-screen computer-implemented graphical userinterface displaying a plurality of devices for simulation by asimulator in accordance with one embodiment of the present invention.

FIG. 11 shows an exemplary on-screen computer-implemented graphical userinterface for configuring a created device in accordance with oneembodiment of the present invention.

FIG. 12 shows an exemplary on-screen computer-implemented graphical userinterface displaying a grouping of devices in accordance with oneembodiment of the present invention.

FIG. 13 shows an exemplary on-screen computer-implemented graphical userinterface using an object-based approach for configuring a simulator inaccordance with one embodiment of the present invention.

FIG. 14 shows an exemplary on-screen computer-implemented graphical userinterface with a device grouping including a plurality of devices inaccordance with one embodiment of the present invention.

FIG. 15 shows an exemplary on-screen computer-implemented graphical userinterface for presenting data associated with a simulation of aplurality of devices in accordance with one embodiment of the presentinvention.

FIG. 16 shows an exemplary computer system platform upon whichembodiments of the present invention may be implemented.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to embodiments of the presentinvention, examples of which are illustrated in the accompanyingdrawings. While the present invention will be discussed in conjunctionwith the following embodiments, it will be understood that they are notintended to limit the present invention to these embodiments alone. Onthe contrary, the present invention is intended to cover alternatives,modifications, and equivalents which may be included with the spirit andscope of the present invention as defined by the appended claims.Furthermore, in the following detailed description of the presentinvention, numerous specific details are set forth in order to provide athorough understanding of the present invention. However, embodiments ofthe present invention may be practiced without these specific details.In other instances, well-known methods, procedures, components, andcircuits have not been described in detail so as not to unnecessarilyobscure aspects of the present invention.

Notation and Nomenclature

Some regions of the detailed descriptions which follow are presented interms of procedures, logic blocks, processing and other symbolicrepresentations of operations on data bits within a computer memory.These descriptions and representations are the means used by thoseskilled in the data processing arts to most effectively convey thesubstance of their work to others skilled in the art. In the presentapplication, a procedure, logic block, process, or the like, isconceived to be a self-consistent sequence of steps or instructionsleading to a desired result. The steps are those requiring physicalmanipulations of physical quantities. Usually, although not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated in a computer system.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the followingdiscussions, it is appreciated that throughout the present invention,discussions utilizing the terms such as “aborting,” “accepting,”“accessing,” “adding,” “adjusting,” “analyzing,” “applying,”“assembling,” “assigning,” “balancing,” “blocking,” “calculating,”“capturing,” “combining,” “comparing,” “collecting,” “configuring,”“creating,” “debugging,” “defining,” “delivering,” “depicting,”“detecting,” “determining,” “displaying,” “establishing,” “executing,”“forwarding,” “flipping,” “generating,” “grouping,” “hiding,”“identifying,” “initiating,” “instantiating,” “interacting,”“modifying,” “monitoring,” “moving,” “outputting,” “performing,”“placing,” “presenting,” “processing,” “programming,” “querying,”“removing,” “repeating,” “resuming,” “sampling,” “simulating,”“sorting,” “storing,” “subtracting,” “suspending,” “tracking,”“transcoding,” “transforming,” “unblocking,” “using,” or the like, referto the action and processes of a computer system, or similar electroniccomputing device, that manipulates and transforms data represented asphysical (electronic) quantities within the computer system's registersand memories into other data similarly represented as physicalquantities within the computer system memories or registers or othersuch information storage, transmission or display devices.

Overview of the Simulation Platform

FIG. 1 shows exemplary system 100 for accessing and processing data fromphysical devices, e.g., sensor devices, in accordance with oneembodiment of the present invention. The sensor devices may be remoteand distributed in large numbers. Within system 100, the devices mayalso receive and respond to commands. As shown in FIG. 1, deviceabstraction layer 110 enables communication between device environment120 and business applications 130, where device environment 120 includesactual or physical devices 125 a-125 d. For example, device datagenerated by one or more of devices 125 a-125 d may be communicated tobusiness applications 130 via device abstraction layer 110. Thecommunicated data, or information associated therewith, may be accessedby end user 140, enterprise resource planning (ERP) system 150, othersystem 160, or some combination thereof, each of which are coupled tobusiness applications 130 as shown in FIG. 1. In other embodiments, datamay be alternatively communicated within system 100 (e.g., data input orgenerated by user 140, ERP system 150, or other system 160 may becommunicated to one or more of devices 125 a-125 d, etc.).

In one embodiment, system 100 may enable monitoring or tracking of datagenerated by devices 125 a-125 d. For example, devices 125 a-125 d maybe sensors, embedded devices, portable electronic devices, or components(e.g., each within a different portion of a manufacturing line, anautomobile, etc.) which measure parameters of device environment 120(e.g., the manufacturing line, automobile, etc.). The devices (e.g., 125a-125 d) may output device data based upon those measurements. Thedevice data may be accessed and/or processed by business applications130 (e.g., accessed via device abstraction layer 110) to enable trackingor monitoring of the device environment (e.g., 120) by a user (e.g.,140) and/or another system (e.g., ERP system 150, other system 160,etc.).

Although only four devices (e.g., 125 a-125 d) are shown within deviceenvironment 120 in FIG. 1, it should be appreciated that deviceenvironment 120 may include any number of devices in other embodiments.For example, system 100 may enable communication with a very largenumber (e.g., hundreds, thousands, millions, etc.) of devices, where thedevices may be distributed remotely in one embodiment. Additionally, itshould be appreciated that more than one device environment may becoupled to device abstraction layer 110 in other embodiments. Forexample, where device environment 120 represents a single automobile andsystem 100 is capable of accessing and/or processing data from millionsof automobiles, then there may be a large number (e.g., millions, etc.)of device environments coupled to device abstraction layer 110 in otherembodiments. Further, in one embodiment, device environment 120 mayinclude devices (e.g., 125 a-125 d) which are physically separate fromone another (e.g., each disposed in different automobiles which arethousands of miles apart). As another example, the sensors could betemperature sensors distributed over a large building, where the sensorsmay be in communication with a fire system, etc.

As shown more fully in FIG. 2, embodiments of the present inventionprovide for simulation of the physical devices for performance testingof device abstraction layer 110 and/or business applications 130.Embodiments also provide for an efficient mechanism for generatingdevices for simulation.

FIG. 2 shows exemplary system 200 for simulating a plurality of devicesin accordance with one embodiment of the present invention. As shown inFIG. 2, simulator 220 may be configured to simulate the responses,outputs, behavior, etc., of devices 225 a-225 d (e.g., corresponding todevices 125 a-125 d of FIG. 1). Simulated devices 225 a-225 d may besimulated sensors, simulated embedded devices, simulated portableelectronic devices, other types of simulated devices, or somecombination thereof. In one embodiment, any device capable of receivingcommands and generating output may be simulated.

During simulation of the devices (e.g., 225 a-225 d), simulator 220 mayoutput simulated device data for the devices (e.g., 225 a-225 d), wherethe simulated device data may represent a data value (e.g., atemperature in degrees Fahrenheit) instead of a signal voltage level(e.g., 1.25 volts) in one embodiment. The simulated device data may beaccessed (e.g., via device abstraction layer 110) and/or processedsimilar to the device data output by devices 125 a-125 d as explainedwith respect to FIG. 1.

It is appreciated that simulator 220 may be used to perform load testingor otherwise analyze the performance of a component of a system undertest (e.g., components of device abstraction layer 110, components ofbusiness applications 130, etc.). The analysis may be based upon aresult of the component's processing of the simulated device data (e.g.,output by simulator 220 for devices 225 a-225 d). Additionally, suchanalysis may be advantageously performed without deploying actualhardware (e.g., devices 125 a-125 d) in one embodiment.

FIG. 3 shows exemplary system 200 for configuring a simulator andsimulating a plurality of devices based upon a specified configurationin accordance with one embodiment of the present invention. FIG. 3 willbe described in conjunction with FIGS. 4A and 4B, where FIGS. 4A and 4Bshow a flowchart of exemplary computer-implemented process 400 forconfiguring a simulator and simulating a plurality of devices based upona specified configuration in accordance with one embodiment of thepresent invention.

Step 410 involves configuring a simulator to simulate a plurality ofdevices. As shown in FIG. 3, simulator configuration graphical userinterface (GUI) 370 is coupled to simulator 220 for configurationthereof. More specifically, configuration data generated based upon userinteraction with GUI 370 (e.g., implemented in accordance with one ormore of FIGS. 6-14) may be accessed by simulation engine 322 and storedin database 324 (e.g., for access by simulation engine 322 duringsimulation of devices 225 a-225 d). The configuration data may begenerated based upon one or more attributes defined for a device profile(e.g., using GUI 370) and/or for one or more devices automaticallygenerated, e.g., instantiated, based upon the device profile (e.g.,using GUI 370). The instantiated devices can be simulated. For example,the configuration data may include a format (e.g., integer, string,decimal, hex, etc.) of the simulated device data output by simulator220, a rate at which simulated device data is output by simulator 220, arange of values for the simulated device data (e.g., a temperature rangefor output data of a simulated temperature sensor), an operatingparameter (e.g., battery life) of one or more of the simulated devices,etc.

In one embodiment, step 410 may involve a user defining a device profile(e.g., using GUI 370) with prescribed attributes that define a type orclass of devices. The user may also advantageously define a number ofdevices (e.g., 225 a-225 d) to be automatically generated (e.g., usingGUI 370) based upon the device profile. The devices may be configuredindividually and/or in groups. Additionally, the communicative couplingof the devices may be defined in step 410 in one embodiment. Further,device configuration data may be generated and/or stored in step 410based upon the user interaction with the GUI (e.g., 370) for definingthe device profile and/or devices (e.g., generated automatically basedupon the device profile).

Step 420 of process 400 involves configuring a device abstraction layer(e.g., 110) to implement communication with the simulator (e.g., 220).For example, device configuration management component 312 of devicemanagement component 311 may download the configuration data (e.g.,generated in step 410) from simulator 220 and store it in database 315of device abstraction layer 110. Data may be accessed by component 312via data access layer 314 in one embodiment. Component 312 may configuredevice abstraction layer 110 based upon the downloaded configurationdata (e.g., stored in database 315) to enable communication withsimulator 220. For example, component 312 may determine a format, size,etc. (e.g., from the configuration data) of the simulated device dataoutput from simulator 220, thereby enabling device abstraction layer 110to access, process, communicate, etc., the simulated device data.

As shown in FIG. 4A, step 430 involves the simulator automaticallyinstantiating the plurality of devices (e.g., 225 a-225 d) forsimulation by the simulator. For example, individual memory constructsand/or data structures may be created and/or populated based upon deviceconfiguration data generated in step 410, thereby “instantiating” thedevices for simulation. The created data structure for each device to besimulated includes the information required to simulate the deviceincluding device profile attributes and/or device state data. The datastructure may include attributes associated with one device, a group ofdevices, a device profile (e.g., used to define a plurality of devices),or some combination thereof. The attributes may include a format foroutput of simulated device data, a rate at which the simulated devicedata is output by the simulator, a range of values for the simulateddevice data, an operating parameter of a device for inclusion in thesimulated device data output by the device, current device state data,etc. And in one embodiment, the data structure may be a table organizedinto rows associated with different device types and columns associatedwith devices of each respective device type, and therefore, each cell ofthe table may include the attributes defined for the device associatedwith that cell and/or attributes defined for a device profile upon whichthe device is based. Further, although the instantiation of theplurality of devices is shown between steps 420 and 435 in FIG. 4, itshould be appreciated that the instantiation of the plurality of devicesmay occur at any time after user-configuration of the devices and beforesimulation of the plurality of devices.

Step 435 involves initiating simulation of the plurality of instantiateddevices (e.g., instantiated in step 430). In one embodiment, thesimulation may be initiated in response to an interaction with a buttonor graphical object (e.g., 1080) of a GUI (e.g., 600 of FIG. 10) forconfiguring the simulator.

Step 440 involves communicating a request to a device abstraction layerfor commands associated with the plurality of devices (e.g., 225 a-225d). For example, notification client 326 of simulator 220 maycommunicate a request (e.g., 325) to notification management component317 of device abstraction layer 110, where the request is for anycommands associated with any of the simulated devices (e.g., 225 a-225d).

As shown in FIG. 4A, step 450 involves the simulator accessing commandscommunicated from the device abstraction layer (e.g., 110). One or morecommands 318 may be communicated to simulator 220 in response to therequest (e.g., 325) received from a simulator (e.g., 220). The commandsmay include a request for simulated device data from one or more of thedevices (e.g., 225 a-225 d), a request to change the frequency at whichsimulator 220 outputs the simulated device data for the devices (e.g.,225 a-225 d), a customized command for execution by one or more of thedevices, or some combination thereof. Additionally, one or more receivedcommands (e.g., 318) may be forwarded (e.g., represented by arrow 327 ofFIG. 3) from a notification client (e.g., 326) to a device applicationprogramming interface (API) (e.g., 328) for execution in one embodiment.The commands may include identification information specifying anintended device for the command. It is appreciated that a command mayalso be specified for a class or grouping of devices as the case may be.

As shown in FIG. 4B, step 460 involves automatically and simultaneouslysimulating a plurality of instantiated devices (e.g., 225 a-225 d) basedupon execution of the commands. For example, simulator 220 (e.g.,simulation engine 322) may generate and/or output simulated device datain response to execution of a command for simulated output data, therebysimulating an output of device data from the plurality of devices. Asanother example, simulator 220 (e.g., simulation engine 322) may adjustan output frequency for simulated device data (e.g., a frequency atwhich the device automatically outputs data) for one or more of thedevices in response to execution of a command to change the outputfrequency of simulated device data, thereby simulating a deviceresponding to a configuration change affecting the frequency at whichthe device automatically outputs device data. And as a further example,simulator 220 (e.g., simulation engine 322) may perform a customizedoperation (e.g., not reporting simulated device data for a predeterminedperiod of time for one or more devices, report simulated device dataoutside a predefined range to indicate the device has been placed in analternate operating mode, etc.) in response to execution of a customizedcommand, thereby simulating performance of a customized command oroperation by the device.

Simulation in step 460 may only be performed for “enabled” devices inone embodiment. For example, only commands associated with enableddevices (e.g., enabled using button or region 1060 of GUI 600 as shownin FIG. 10) may be executed in step 460. Commands for “disabled” devices(e.g., disabled using button or region 1070 of GUI 600 as shown in FIG.10) may be ignored, and therefore, disabled devices may not be simulatedin one embodiment.

Step 470 involves generating simulated device data during simulation ofthe plurality of devices (e.g., 225 a-225 d). As discussed herein,simulator 220 (e.g., simulation engine 322) may generate the simulateddevice data in response to a command (e.g., 318) from device abstractionlayer 110 (e.g., notification management component 317). The simulateddevice data may be generated in accordance with configuration data(e.g., accessed from database 324), and therefore, the simulated devicedata may have a format, type, size, arrangement, content, etc., definedby the configuration data.

As shown in FIG. 4B, step 480 involves communicating the simulateddevice data to a component coupled to the simulator (e.g., 220). Asdiscussed herein, simulator 220 (e.g., simulation engine 322) may outputthe simulated device data in response to a command (e.g., 318) fromdevice abstraction layer 110 (e.g., notification management component317). The simulated device data (e.g., 329) may be communicated todevice monitoring component 313 of device abstraction layer 110 (e.g.,via data access layer 314) in one embodiment, where component 313 mayprocess the received simulated output data. And in one embodiment, thesimulated device data may be communicated to a component of businessapplications 130 and/or another component coupled thereto.

Step 490 involves analyzing the performance of the component based upona result of the processing of the simulated device data by the component(e.g., of device abstraction layer 110, of business applications 130,etc.). In this manner, the component accessing and/or processing thesimulated device data may be load tested to determine or improveprocessing efficiency of the component, perform debugging operations onthe component, or the like. As another example, the number of simulateddevices, the arrangement of simulated devices, the format or othercharacteristics of the simulated device data output by the simulateddevices, etc., may be varied to further test the component.

As shown in FIG. 4B, step 495 involves presenting the results of thesimulation (e.g., performed in one or more of steps 430 to 470) and/orpresenting the analysis of the component (e.g., generated in step 490).The data may be presented using a GUI (e.g., GUI 380 of FIG. 3) coupledto the simulator (e.g., 220). Additionally, in one embodiment, the GUIfor presenting the data in step 495 may be implemented in accordancewith GUI 1500 of FIG. 15.

Turning to FIG. 15, FIG. 15 shows exemplary on-screencomputer-implemented GUI 1500 for presenting data associated with asimulation of a plurality of devices in accordance with one embodimentof the present invention. As shown in FIG. 15, GUI 1500 includes data incolumns 1530-1550 associated with the devices listed in columns 1510 and1520. For example, row 1560 is associated with the device (e.g., one ofdevices 225 a-225 d) identified by the device identifier in column 1510of row 1560 (e.g., “TS120”) and the device name in column 1520 of row1560 (e.g., “Device A”). In one embodiment, the information listed incolumn 1510 for each device may be entered using region 1130 of GUI1100, while the information listed in column 1520 may be entered usingregion 1140 of GUI 1100.

Column 1530 contains simulated device data for each of the devicesidentified in columns 1510 and 1520. For example, where each of thedevices are simulated temperature sensors, the data listed in column1530 may be temperature readings (e.g., in degrees Fahrenheit, indegrees Celsius, etc.). Each row of column 1540 may include the date andtime at which a respective data value of column 1530 was captured orgenerated. Additionally, each row of column 1550 may include a batterystatus of a simulated device (e.g., identified in a respective row ofcolumn 1510 and/or 1520). The battery status in column 1550 may becaptured or generated at a time identified in a respective row of column1540 in one embodiment.

The data listed in one or more of columns 1530-1550 may be used todetermine if a device is working correctly in one embodiment. Forexample, where a data range is specified for a plurality of devices(e.g., using region 1160 of GUI 1100), then a data value reported by thesimulator (e.g., 220) and listed in column 1530 may indicate a problemwith a device reporting a value outside of that range. For example,where a range of 40-90 is specified (e.g., using region 1160), then thedata values in rows 1570 and 1580 of column 1530 may indicate that twodevices (e.g., “Device C” of row 1570 and “Device H” of row 1580) arenot operating properly since they are not within the range of 40-90.Similarly, unexpected data values reported in columns 1540 and/or 1550may also indicate a problem with a sensor. In this manner, embodimentsenable the simulation of faulty or inoperable devices, thereby improvingthe accuracy and/or realism of the simulation. The data from the faultyor inoperable devices may also enable the analysis of components whichaccess this data, for example, as discussed with respect to step 490 ofFIG. 4B.

In one embodiment, the reliability of the simulated devices may bealtered (e.g., by configuring one or more devices using a GUI such asGUI 370, GUI 600, GUI 700, GUI 900, GUI 1100, GUI 1300, etc.) tosimulate real-world device failure. In this manner, the simulator (e.g.,220) may simulate one or more faulty or inoperable devices, andtherefore, cause one or more devices to report bad data (e.g., outside apredetermined range as discussed herein, etc.). For example, if a deviceis configured to have a 95% reliability factor or rate, then the devicemay report good data 95% of the time and report bad data the other 5% ofthe time.

Although FIG. 15 show the presentation of specific data, it should beappreciated that GUI 1500 may include other data related to a simulationof devices (e.g., 225 a-225 d) and/or analysis of a component accessingsimulated device data (e.g., as discussed with respect to step 490 ofFIG. 4B). Additionally, it should be appreciated that GUI 1500 may alsoenable a user to view past data transmissions (e.g., simulated devicedata generated in the past) of one or more simulated devices (e.g., 225a-225 d).

Configuring the Simulator

FIGS. 5A and 5B show a flowchart of exemplary process 500 forconfiguring a simulator in accordance with one embodiment of the presentinvention. Process 500 may be used implement step 410 of process 400 ofFIGS. 4A and 4B in one embodiment. Additionally, FIGS. 5A and 5B will bedescribed in conjunction with FIGS. 6 through 14 which show exemplaryGUIs for configuring a simulator in accordance with embodiments of theinvention.

As shown in FIG. 5A, step 510 involves displaying one or morecomputer-implemented graphical user interfaces (GUIs) for creatingand/or configuring a device profile. A device profile may be a templateor collection of configurable attributes (e.g., defined by a user usingthe GUIs) which may be used to create a plurality of device (e.g., 225a-225 d) in one embodiment. The one or more GUIs displayed in step 510may be presented on a display device for interaction with a user,thereby enabling a user to create and/or configure a device profile.Additionally, the GUIs displayed in step 510 may be implemented inaccordance with GUI 370 of FIG. 3, GUI 600 of FIG. 6, GUI 700 of FIG. 7,GUI 800 of FIG. 8, another GUI, some combination thereof, etc.

FIG. 6 shows exemplary on-screen computer-implemented GUI 600 forconfiguring a simulator in accordance with one embodiment of the presentinvention. For example, as shown in FIG. 6, interaction with region 610of GUI 600 may initiate display of region 620. Region 620 may be apop-up menu with selectable menu items for creating, editing, anddeleting a device profile. Interaction with a selectable menu item ofregion 620 (e.g., selectable menu item 622 for creating a deviceprofile, selectable menu item 624 for editing an existing deviceprofile, etc.) may initiate display of GUI 700 of FIG. 7 and/or GUI 800of FIG. 8 in one embodiment.

FIG. 7 shows exemplary on-screen computer-implemented GUI 700 fordefining a device profile in accordance with one embodiment of thepresent invention. GUI 700 may be used to create a new device profile inone embodiment. For example, display regions 710-730 may be used tospecify information about the device profile, display regions 740-770may be used define values for predetermined attributes, and displayregion 780 may be used to define new attributes (e.g., displayed inregion 785). Alternatively, GUI 700 may be used to edit an existingdevice profile. For example, information entered into regions 710-730may be edited and/or values for predetermined attributes may bere-defined using regions 740-770. Additionally, a user may edit anexisting device profile by interacting with region 780 to re-define anexisting custom attribute (e.g., displayed in region 785) and/or definenew custom attributes (e.g., which may then be displayed in region 785).

As shown in FIG. 7, regions 710-730 may be used to enter information forthe device profile. For example, region 710 may be used to enter anidentifier (e.g., “28”) for the device profile, where the profileidentification number may distinguish device profiles (e.g., of the samedevice profile type) with different attributes from one another. Aprofile type (e.g., “sensor”) for the device profile may be definedusing region 720. For example, if the device profile is associated witha sensor using region 720, then the devices created from the deviceprofile may be simulated sensors in one embodiment. Additionally, region730 may be used to enter a name for the device profile, where theprofile name may distinguish device profiles (e.g., of the same deviceprofile type) with different attributes from one another.

Regions 740-770 may be used to define values for predeterminedattributes. For example, region 740 may be used to define a profile datarange. The profile data range may be an expected range associated withthe simulated output data output by a simulator (e.g., 220) for aplurality of devices (e.g., 225 a-225 d). Additionally, the simulator(e.g., 220) may access the data range entered into region 740 andgenerate simulated device data for one or more simulated devices (e.g.,225 a-225 d) which falls within the range entered into region 740.

Region 750 may be used to define a frequency for generating oroutputting simulated device data for the plurality of devices. Forexample, if a value of “2” is entered into region 750, then thesimulator (e.g., 220) may output simulated device data for a simulateddevice (e.g., created based upon the device profile defined using GUI700) every 2 minutes (e.g., where the unit of frequency associated withregion 750 is minutes).

As shown in FIG. 7, a battery life may be defined for the devices usingregion 760. For example, if a value of “2” is entered into region 760,then a battery life of 2 days (e.g., where the unit of battery lifeassociated with region 760 is days) may be associated with a devicecreated based upon the device profile defined using GUI 600.

Region 770 may be used to define a format for the simulated device dataoutput for simulated devices (e.g., 220 a-220 d) created based upon adevice profile defined using GUI 600. In one embodiment, the format maycorrespond to how the simulated device data for the plurality of devices(e.g., created based upon the device profile defined using GUI 700) isassembled. Additionally, a format defined using region 770 may includedecimal, integer, string, hex, another format, etc.

Interaction with button or region 780 may initiate display of GUI 800 ofFIG. 8 in one embodiment, where FIG. 8 shows exemplary on-screencomputer-implemented GUI 800 for defining a custom attribute inaccordance with one embodiment of the present invention. Region 810 maybe used to define a name for the custom attribute, region 820 may beused to define an attribute type for the custom attribute (e.g., how thecustom attribute will be expressed in the simulated device data), region830 may be used to specify a description of the custom attribute, andregion 840 may be used to define a data range for the simulated devicedata corresponding to the custom attribute (e.g., similar to thepredefined attribute data range defined using region 740 of FIG. 7).Additionally, interaction with button or region 850 may associate theinformation defined in regions 810-840 with the device profile (e.g.,defined using GUI 700) and present the information in region 785 of GUI700.

Turning back to FIG. 5A, step 515 involves associating one or moreattributes with the device profile (e.g., crated using GUI 700 and/orGUI 800). The one or more attributes may be predefined attributes (e.g.,associated with regions 740-770) and/or custom attributes (e.g., definedusing GUI 800 and presented in region 785). Additionally, the one ormore attributes may be associated with the device profile in response tointeraction with button or region 790 in one embodiment.

Step 520 involves displaying a GUI for creating devices (e.g., to besimulated) based upon the device profile (e.g., created using GUI 700,GUI 800, etc.). The one or more GUIs displayed in step 520 may bepresented on a display device for interaction with a user, therebyenabling a user to create a device for simulation by a simulator (e.g.,220). Additionally, the GUI displayed in step 520 may be implemented inaccordance with GUI 370 of FIG. 3, GUI 600 of FIG. 6, GUI 900 of FIG. 9,etc.

FIG. 9 shows exemplary on-screen computer-implemented GUI 900 forcreating a device based upon a device profile in accordance with oneembodiment of the present invention. As shown in FIG. 9, region 910 maybe used to specify a device profile (e.g., created using GUI 600) uponwhich simulated devices are to be created. Region 920 may indicate atype of profile selected or defined using region 910. Region 930 may beused to specify a number of devices to be created based upon the deviceprofile (e.g., selected using region 910). In this manner, embodimentsof the present invention enable users to easily create a plurality ofdevices (e.g., for simulation by a simulator) based upon a selecteddevice profile, where the created devices may be instantiated based uponinformation entered into GUI 900 (e.g., as discussed with respect tostep 430 of FIG. 4A) and simulated (e.g., as discussed with respect toone or more of steps 435 to 480 of FIGS. 4A and 4B).

Region 940 may enable a user to specify a name or root identifier forone or more of the devices created based upon the selected deviceprofile. Additionally, a description of the one or more devices may beentered in region 950.

Turning back to FIG. 5A, step 525 involves associating the deviceprofile with the devices. For example, interaction with button or region960 of GUI 900 may associate the device profile (e.g., selected usingregion 910) with one or more devices (e.g., a number of devicesspecified in region 930). Once created, the devices may be displayed inregion 1030 of GUI 600 (e.g., as shown in FIG. 10).

FIG. 10 shows exemplary on-screen computer-implemented GUI 600displaying a plurality of devices for simulation by a simulator inaccordance with one embodiment of the present invention. As shown inFIG. 10, region 1030 may present one or more of the created devices(e.g., using GUI 900 based upon a profile defined using GUI 600). Thecreated devices may be further configured or edited by interaction withregion 1055, where region 1055 may initiate display of GUI 1100 of FIG.11 in one embodiment. Further, in one embodiment, region 1050 (e.g.,including region 1055) may be displayed in response to interaction withregion 1040.

Turning to FIG. 5B, step 530 involves displaying a GUI for configuringthe devices (e.g., created using GUI 900). The one or more GUIsdisplayed in step 530 may be presented on a display device forinteraction with a user, thereby enabling a user to further configure adevice for simulation by a simulator (e.g., 220). Additionally, the GUIdisplayed in step 530 may be implemented in accordance with GUI 370 ofFIG. 3, GUI 1100 of FIG. 11, etc.

FIG. 11 shows exemplary on-screen computer-implemented GUI 1100 forconfiguring a created device in accordance with one embodiment of thepresent invention. As shown in FIG. 11, region 1110 may be used tochange or define a profile name (e.g., similar to region 910 of FIG. 9).Region 1120 may be used to change or define a profile type (e.g.,similar to region 920 of FIG. 9). Region 1130 may be used to change ordefine a device identifier (e.g., assigned automatically upon creationof multiple devices using GUI 900).

Region 1140 may be used to change or define a device name (e.g., similarto region 940 of FIG. 9). In one embodiment, the device name displayedin region 1140 may be automatically assigned upon creation of multipledevices using GUI 900. Additionally, region 1150 may be used to changeor define a device description (e.g., similar to region 950 of FIG. 9).In one embodiment, the device description displayed in region 1150 maybe automatically assigned upon creation of multiple devices using GUI900.

As shown in FIG. 11, region 1160 may be used to change or define adevice data range (e.g., similar to region 740 of FIG. 7). Region 1170may be used to change or define a frequency for generating or outputtingsimulated device data for the plurality of devices (e.g., similar toregion 750 of FIG. 7). Additionally, a battery life may be defined forthe devices using region 1180 (e.g., similar to region 760 of FIG. 7).Region 1190 may be used to define a format for simulated device data(e.g., similar to region 770).

Interaction with button or region 1192 may enable a user to define acustom attribute (e.g., similar to button or region 780 of FIG. 7),where the interaction with region 1192 may initiate display of GUI 800of FIG. 8 in one embodiment. Additionally, interaction with button orregion 1194 may apply the changes made to the device using GUI 1100and/or initiate display of GUI 600 (e.g., of FIG. 6, FIG. 10, etc.).

As shown in FIG. 10, a device (e.g., presented in region 1030) may beenabled for inclusion in a group of devices to be simulated using buttonor region 1060. Alternatively, an enabled device (e.g., presented inregion 1030) may be disabled for removing the device from a group ofdevices to be simulated, where the device may be disabled using buttonor region 1070.

Turning back to FIG. 5B, step 532 involves accessing configurationinformation for the devices. The configuration information accessed instep 532 may be based upon information entered using GUI 600, GUI 700,GUI 800, or some combination thereof. In one embodiment, theconfiguration information may include information entered using GUI 900and/or GUI 1100.

Step 534 involves accessing grouping information defined for thedevices. The grouping information accessed in step 534 may includeinformation about a number of groups into which devices (e.g., thosecreated using GUI 900) are organized, a name of each device grouping, alisting of specific devices in each group, and the like. It isappreciated that the simulator may respond to a command given to adevice group. Additionally, the grouping information may includeconfiguration information defined for a group (e.g., a data rangeapplied to all devices of a group, etc.). Information about acommunicative coupling of the devices may also be included in thegrouping information. For example, information about how the devices arearranged with respect to one another and/or the arrangement ofcommunication channels or paths coupling the devices may be included inthe grouping information accessed in step 534. Further, in oneembodiment, the grouping information may be accessed based uponinteraction with GUI 600 as shown in FIG. 12, GUI 1300 as shown in FIGS.13 and/or 14, or the like.

FIG. 12 shows exemplary on-screen computer-implemented GUI 600displaying a grouping of devices in accordance with one embodiment ofthe present invention. Grouping devices helps in managing data to andfrom the group. Additionally, grouping devices can also help inassigning group functionality or attributes for implementation duringsimulation of devices from the group. As stated above, device groups canreceive and respond to commands within the simulation architecture.

As shown in FIG. 12, devices displayed within region 1030 may be groupedinto a plurality of groups. For example, devices 1215 may be groupedinto first group 1210, while devices 1225 may be grouped into secondgroup 1220. Grouping may be performed, in one embodiment, byhighlighting or otherwise selecting devices to be grouped (e.g., devices1215, devices 1225, etc.) and interacting with region 1252 (e.g., ofregion 1050) to group the devices.

Once a grouping of devices is created, information or attributes foreach device within the grouping may be changed or defined (e.g., using aGUI for configuring a device grouping). For example, changing a datarange of the simulated device data for the group of devices may changeand/or override a data range entered for individual devices of thegroup.

Additionally, information about a communicative coupling of the devicesmay be defined using GUI 600 in one embodiment. For example, thesimulator (e.g., 220) may be configured to generate and/or outputsimulated device data for a single device (e.g., “Device A”) even thoughthe group of device comprise multiple devices (e.g., “Device A,” “DeviceB,” and “Device C”). As another example, the simulator (e.g., 220) maybe configured to generate and/or output simulated device data for agroup which represents an average of the respective simulated devicedata associated with each device of the group.

FIG. 13 shows exemplary on-screen computer-implemented GUI 1300 using anobject-based approach for configuring a simulator in accordance with oneembodiment of the present invention. For example, devices to besimulated may be placed in display region 1320, where the devices may beconfigured by a user for simulation. More specifically, deviceconfiguration data may be generated based upon user-configuration ofdevices placed in region 1320, where the configuration may includeindividual device configuration (e.g., defining one or more attributesfor a given device), group device configuration (e.g., defining anattribute for a group of devices, defining which devices are included ina given device group, etc.), a communicative coupling of devices ordevice groups, and the like. The device configuration data may be usedby the simulator (e.g., 220) to instantiate and simulate the devices(e.g., to generate simulated device data for the devices based upon theconfiguration, etc.).

As shown in FIG. 13, region 1310 of GUI 1300 includes device object1311, group object 1312, hub object 1313, average object 1314, andselect object 1315. Instances of objects 1311-1315 may be placed inregion 1320 (e.g., by dragging and dropping one of objects 1311-1315into region 1320) for defining components corresponding to the objects.For example, device object 1311 may be dragged and dropped in region1320 to create device 1311 a (e.g., similar to one of simulated devices225 a-225 d), where device 1311 a may be a device for simulation by asimulator (e.g., 220).

Group object 1312 may be dragged and dropped in region 1320 to createdevice group (e.g., 1312 a), where the device group may be a group ofdevices for simulation by a simulator. For example, group 1312 a mayinclude three devices as indicated by the number “3” within group 1312a. Further, the devices within a device group (e.g., 1312 a) may beviewed by interacting with the device group (e.g., the graphical objectrepresenting device group 1312 a), where FIG. 14 shows exemplaryon-screen computer-implemented GUI 1300 with a device grouping includinga plurality of devices in accordance with one embodiment of the presentinvention. As shown in FIG. 14, device group 1312 a may include devices1311 h, 1311 i, and 1311 j.

Turning back to FIG. 13, hub object 1313 may be dragged and dropped inregion 1320 to create a hub component (e.g., 1313 a), where the hubcomponent may be a data hub for accessing, packaging, and communicatingsimulated output data from multiple devices or device groups. Averageobject 1314 may be dragged and dropped in region 1320 to create anaverage component (e.g., 1314 a), where the average component may be acomponent for generating new simulated output data based upon an averageof simulated device data for multiple devices (e.g., 1311 c and 1311 d).Additionally, select object 1315 may be dragged and dropped in region1320 to create a select component (e.g., 1315 a), where the selectcomponent may be a component for communicating simulated device data(e.g., the simulated device data of device 1311 e, 1311 f, or 1311 g)selected from the simulated device data for multiple devices (e.g., 1311e, 1311 f and 1311 g).

In one embodiment, objects may be placed and/or arranged in region 1320by dragging and dropping objects from region 1310, by dragging anddropping objects to new locations within region 1320, or the like.Additionally, a communicative coupling may be defined using toolsselected from region 1330, where the tools of region 1330 may include aline tool (e.g., for connecting or coupling one object to another, oneobject to a group of objects, a group of objects to another group ofobjects, etc.) and/or other tools. In this manner, devices 1311 c and1311 may each be connected or coupled to average component 1314, devicegroup 1312 a may be connected or coupled to hub component 1313 b, or thelike.

Accordingly, GUI 1300 may be used to define how simulated device data isaccessed, collected, and communicated. For example, hub component 1313 bmay access and/or package simulated device data from device group 1312 a(e.g., outputting simulated device data for each of the devices ofdevice group 1312 a) and average component 1314 (e.g., outputtingsimulated device data representing an average of the simulated devicedata from devices 1311 c and 1311 d). Hub component 1313 c may accessand/or package simulated device data from select component 1315 (e.g.,outputting simulated device data from device 1311 e, 1311 f, or 1311 g),device 1311 a, device 1311 b, and device group 1312 b (e.g., outputtingsimulated device data for each of the devices of device group 1312 b).Further, hub component 1313 a may access and/or package simulated devicedata from hub components 1313 b and 1313 c. In this manner, embodimentsenable a user to define an arrangement and/or communicative coupling ofdevices which may more accurately represent an arrangement of actualdevices (e.g., corresponding to each of the simulated components) in adevice environment (e.g., 120 of FIG. 1).

Components defined using objects 1311-1315 may be configured using GUI1300. For example, user interaction with an object representing thecomponent to be configured may display a GUI (e.g., 1100 of FIG. 11,etc.) for defining attributes or otherwise configuring the component.Alternatively, the communication paths coupling the components in region1320 may be configured. For example, path 1340 may be configured (e.g.,by displaying a GUI or other configuration mechanism for configuring apath in response to a user interaction with path 1340) to report datafor less than all of the devices of group 1312 a.

Turning back to FIG. 5B, step 540 involves generating configuration databased upon configuration of a device profile and/or devices (e.g., 225a-225 d). For example, information entered using a GUI for defining adevice profile (e.g., GUI 370, GUI 600, GUI 700, GUI 800, etc.) and/ordefining a device (e.g., GUI 370, GUI 600, GUI 900, GUI 1100, etc.) maybe accessed (e.g., by simulation engine 322) and used to generateconfiguration data. Step 540 may be performed in response to interactionwith button or region 1080 of GUI 600 in one embodiment.

Step 550 involves storing the configuration data for access by thesimulator (e.g., 220) and/or enabling simulation of the devices (e.g.,225 a-225 d). The configuration data may be stored in a memory (e.g.,database 324) accessible to the simulator (e.g., 220). Step 550 may beperformed in response to interaction with button or region 1080 of GUI600 in one embodiment.

Computer System Platform

FIG. 16 shows exemplary general purpose computer system platform 1600upon which embodiments of the present invention may be implemented. Forexample, computer system 1600 may be used to implement one or morecomponents of system 100 in one embodiment. As another example, computersystem 1600 may be used to implement one or more components of system200.

As shown in FIG. 16, portions of the present invention are comprised ofcomputer-readable and computer-executable instructions that reside, forexample, in computer system platform 1600 and which may be used as apart of a general purpose computer network (not shown). It isappreciated that computer system platform 1600 of FIG. 16 is merelyexemplary. As such, the present invention can operate within a number ofdifferent systems including, but not limited to, general-purposecomputer systems, embedded computer systems, laptop computer systems,hand-held computer systems, portable computer systems, and stand-alonecomputer systems, for instance.

In one embodiment, depicted by dashed lines 1630, computer systemplatform 1600 may comprise at least one processor 1610 and at least onememory 1620. Processor 1610 may comprise a central processing unit (CPU)or other type of processor. Depending on the configuration and/or typeof computer system environment, memory 1620 may comprise volatile memory(e.g., RAM), non-volatile memory (e.g., ROM, flash memory, etc.), orsome combination of the two. Additionally, memory 1620 may be removable,non-removable, etc.

In other embodiments, computer system platform 1600 may compriseadditional storage (e.g., removable storage 1640, non-removable storage1645, etc.). Removable storage 1640 and/or non-removable storage 1645may comprise volatile memory, non-volatile memory, or any combinationthereof. Additionally, removable storage 1640 and/or non-removablestorage 1645 may comprise CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store information for access by computer system platform1600.

As shown in FIG. 16, computer system platform 1600 may communicate withother systems, components, or devices via communication interface 1670.Communication interface 1670 may embody computer readable instructions,data structures, program modules or other data in a modulated datasignal (e.g., a carrier wave) or other transport mechanism. By way ofexample, and not limitation, communication interface 1670 may couple towired media (e.g., a wired network, direct-wired connection, etc.)and/or wireless media (e.g., a wireless network, a wireless connectionutilizing acoustic, RF, infrared, or other wireless signaling, etc.).

Communication interface 1670 may also couple computer system platform1600 to one or more input devices (e.g., a keyboard, mouse, pen, voiceinput device, touch input device, etc.). Additionally, communicationinterface 1670 may couple computer system platform 1600 to one or moreoutput devices (e.g., a display, speaker, printer, etc.).

As shown in FIG. 16, graphics processor 1650 may perform graphicsprocessing operations on graphical data stored in frame buffer 1660 oranother memory (e.g., 1620, 1640, 1645, etc.) of computer systemplatform 1600. Graphical data stored in frame buffer 1660 may beaccessed, processed, and/or modified by components (e.g., graphicsprocessor 1650, processor 1610, etc.) of computer system platform 1600and/or components of other systems/devices. Additionally, the graphicaldata may be accessed (e.g., by graphics processor 1650) and displayed onan output device coupled to computer system platform 1600. Accordingly,memory 1620, removable storage 1640, non-removable storage 1645, famebuffer 1660, or a combination thereof, may comprise instructions thatwhen executed on a processor (e.g., 1610, 1650, etc.) implement a methodof configuring a simulator (e.g., 220) and performing a simulation of aplurality of devices (e.g., 225 a-225 d).

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. Thus, the sole and exclusive indicatorof what is, and is intended by the applicant to be, the invention is theset of claims that issue from this application, in the specific form inwhich such claims issue, including any subsequent correction. Hence, nolimitation, element, property, feature, advantage, or attribute that isnot expressly recited in a claim should limit the scope of such claim inany way. Accordingly, the specification and drawings are to be regardedin an illustrative rather than a restrictive sense.

1-28. (canceled)
 29. A computer-implemented method for simulating a plurality of devices, comprising: receiving, by one or more processors, one or more user inputs associated with the plurality of devices; generating, by the one or more processors, configuration data for the plurality of devices based on the one or more user inputs; automatically instantiating, by the one or more processors, the plurality of devices based on the configuration data; receiving, by the one or more processors, commands associated with the plurality of devices; automatically simulating, by the one or more processors, the plurality of devices based on the commands, to generate simulated device data; and providing, by the one or more processors, the simulated device data to a module for performance testing of at least a portion of the module based on the simulated device data.
 30. The computer-implemented method of claim 29, wherein the plurality of devices comprises one or more of a sensor, an embedded device, a portable electronic device, and a data hub for receiving data from a device.
 31. The computer-implemented method of claim 29, wherein the commands comprise requests for the simulated device data, and wherein automatically simulating the plurality of devices comprises executing the commands.
 32. The computer-implemented method of claim 31, wherein the simulated device data comprises packetized data.
 33. The computer-implemented method of claim 31, wherein the configuration data comprises information related to one or more of a format of the simulated device data, a rate at which the simulated device data is provided to the module, a range of values for the simulated device data, an operating parameter of at least one of the plurality of devices, and current device state data for at least one of the plurality of devices.
 34. The computer-implemented method of claim 29, wherein the commands comprise one or more of a request to change an output frequency of the simulated device data and a custom command associated with at least one device of the plurality of devices.
 35. The computer-implemented method of claim 29, wherein the configuration data is associated with at least one attribute of the plurality of devices.
 36. The computer-implemented method of claim 35, wherein the configuration data comprises device profile information.
 37. The computer-implemented method of claim 36, wherein the one or more user inputs are received at a graphical user interface, comprising at least one region associated with the device profile information and at least one region associated with attribute information.
 38. The computer-implemented method of claim 37, wherein the device profile information comprises at least one of a device identifier indication, a profile identification number indication, a profile type indication, a profile name indication, a profile data range indication, a frequency of data indication, a format of data indication, and a battery life indication, and wherein the attribute information comprises at least one of an attribute name indication, an attribute type indication, a description indication, and a data range indication.
 39. The computer-implemented method of claim 29, further comprising providing, by the one or more processors, the configuration data to the module to enable the module to receive the simulated device data.
 40. The computer-implemented method of claim 29, wherein the simulated device data is provided to the module such that the module can process the simulated device date to provide an indicator of performance of the module.
 41. The computer-implemented method of claim 29, wherein the module comprises a device abstraction layer or a business application.
 42. A non-transitory computer-readable storage medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations for simulating a plurality of devices, the operations comprising: receiving one or more user inputs associated with the plurality of devices; generating configuration data for the plurality of devices based on the one or more user inputs; automatically instantiating the plurality of devices based on the configuration data; receiving commands associated with the plurality of devices; automatically simulating the plurality of devices based on the commands, to generate simulated device data; and providing the simulated device data to a module for performance testing of at least a portion of the module based on the simulated device data.
 43. The non-transitory computer-readable storage medium of claim 42, wherein the plurality of devices comprises one or more of a sensor, an embedded device, a portable electronic device, and a data hub for receiving data from a device.
 44. The non-transitory computer-readable storage medium of claim 42, wherein the commands comprise requests for the simulated device data, and wherein automatically simulating the plurality of devices comprises executing the commands.
 45. The non-transitory computer-readable storage medium of claim 44, wherein the simulated device data comprises packetized data.
 46. The non-transitory computer-readable storage medium of claim 44, wherein the configuration data comprises information related to one or more of a format of the simulated device data, a rate at which the simulated device data is provided to the module, a range of values for the simulated device data, an operating parameter of at least one of the plurality of devices, and current device state data for at least one of the plurality of devices.
 47. The non-transitory computer-readable storage medium of claim 42, wherein the commands comprise one or more of a request to change an output frequency of the simulated device data and a custom command associated with at least one device of the plurality of devices.
 48. The non-transitory computer-readable storage medium of claim 42, wherein the configuration data is associated with at least one attribute of the plurality of devices.
 49. The non-transitory computer-readable storage medium of claim 48, wherein the configuration data comprises device profile information.
 50. The non-transitory computer-readable storage medium of claim 49, wherein the one or more user inputs are received at a graphical user interface, comprising at least one region associated with the device profile information and at least one region associated with attribute information.
 51. The non-transitory computer-readable storage medium of claim 50, wherein the device profile information comprises at least one of a device identifier indication, a profile identification number indication, a profile type indication, a profile name indication, a profile data range indication, a frequency of data indication, a format of data indication, and a battery life indication, and wherein the attribute information comprises at least one of an attribute name indication, an attribute type indication, a description indication, and a data range indication.
 52. The non-transitory computer-readable storage medium of claim 42, wherein the operations further comprise providing the configuration data to the module to enable the module to receive the simulated device data.
 53. The non-transitory computer-readable storage medium of claim 42, wherein the simulated device data is provided to the module such that the module can process the simulated device date to provide an indicator of performance of the module.
 54. The non-transitory computer-readable storage medium of claim 42, wherein the module comprises a device abstraction layer or a business application.
 55. A system, comprising: one or more processors; and a computer-readable storage device coupled to the one or more processors and having instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform operations for simulating a plurality of devices, the operations comprising: receiving one or more user inputs associated with the plurality of devices; generating configuration data for the plurality of devices based on the one or more user inputs; automatically instantiating the plurality of devices based on the configuration data; receiving commands associated with the plurality of devices; automatically simulating the plurality of devices based on the commands, to generate simulated device data; and providing the simulated device data to a module for performance testing of at least a portion of the module based on the simulated device data.
 56. The system of claim 55, wherein the plurality of devices comprises one or more of a sensor, an embedded device, a portable electronic device, and a data hub for receiving data from a device.
 57. The system of claim 55, wherein the commands comprise requests for the simulated device data, and wherein automatically simulating the plurality of devices comprises executing the commands.
 58. The system of claim 57, wherein the simulated device data comprises packetized data.
 59. The system of claim 57, wherein the configuration data comprises information related to one or more of a format of the simulated device data, a rate at which the simulated device data is provided to the module, a range of values for the simulated device data, an operating parameter of at least one of the plurality of devices, and current device state data for at least one of the plurality of devices.
 60. The system of claim 55, wherein the commands comprise one or more of a request to change an output frequency of the simulated device data and a custom command associated with at least one device of the plurality of devices.
 61. The system of claim 55, wherein the configuration data is associated with at least one attribute of the plurality of devices.
 62. The system of claim 61, wherein the configuration data comprises device profile information.
 63. The system of claim 62, wherein the one or more user inputs are received at a graphical user interface, comprising at least one region associated with the device profile information and at least one region associated with attribute information.
 64. The system of claim 63, wherein the device profile information comprises at least one of a device identifier indication, a profile identification number indication, a profile type indication, a profile name indication, a profile data range indication, a frequency of data indication, a format of data indication, and a battery life indication, and wherein the attribute information comprises at least one of an attribute name indication, an attribute type indication, a description indication, and a data range indication.
 65. The system of claim 55, wherein the operations further comprise providing the configuration data to the module to enable the module to receive the simulated device data.
 66. The system of claim 55, wherein the simulated device data is provided to the module such that the module can process the simulated device date to provide an indicator of performance of the module.
 67. The system of claim 55, wherein the module comprises a device abstraction layer or a business application. 